>On my system, whereas the manual states that this bit is ignored on >directories, a file created on such a directory is owned by the same >group that posses the dir, and any child directory has the same sgid >bit, by default. This is normal behaviour on the Suns (and I think it's documented somewhere) It isn't a priori a security hole; nevertheless, there may be security implications. In the Elder Days, processes were in exactly one group at a time, and directories were created with the permissions of the effective gid of the process that issued the mkdir(). Berkeley changed that in 4.2bsd to let processes be in more than one group simultaneously. Both to settle the question of what group new files and directories should be in, and also to make the semantics useful, they also decreed that new files should inherit the gid of the directory in which they were created. When Sun and USL got together to merge the SysV/BSD strains of UNIX, this difference in file system semantics was one of the issues that had to be resolved. Someone decided that the setgid bit for a directory could be given a useful meaning, thereby letting administrators and users decide for themselves which semantics they wanted. But no attempt was made to see which programs, if any, would break with either behavior. There was thus mechanism but no grounds for choosing a policy. I protested this at the time, but no one listened. Security implications could arise if a setgid() program created a file or directory under the wrong assumption about who would have permissions on that file. This is most likely to occur with programs that originated on the System V side of the world. I should add, btw, that I don't know of any such holes, but I wouldn't be surprised if some were to appear.